這類還是老老實實花錢找人做吧.
創(chuàng)新互聯(lián)主營榮成網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營網(wǎng)站建設(shè)方案,成都app開發(fā),榮成h5微信小程序搭建,榮成網(wǎng)站營銷推廣歡迎榮成等地區(qū)企業(yè)咨詢
效果好的話代碼量試不會少的，開發(fā)時間至少得是好幾天。
而且你的要求更偏向于flash
[img]關(guān)于js中實例和對象的解釋如下：
比如定義persion如下：
var person = new Object();
var person = {};
JS 是基于原型的面向?qū)ο笳Z言, 所有數(shù)據(jù)都可以當(dāng)作對象處理，所以 person 是對象, 可以把它當(dāng)作是 Object 的實例. 當(dāng)然, 一切都是對象。
第二個采用對象字面量的方式生成的person也是如此。
然而它內(nèi)部沒有調(diào)用new Object()，而是采用JSON的初始化方式：
將現(xiàn)有的引用指向person。
實例和對象的區(qū)別，從定義上來講：
1、實例是類的具象化產(chǎn)品，
2、而對象是一個具有多種屬性的內(nèi)容結(jié)構(gòu)。
實例都是對象，而對象不全是實例。
Js里面沒有類（ES6以前）的語法，所以類的概念就通過創(chuàng)造一個對象來實現(xiàn)。
JavaScript 是一種腳本語言，主要用在瀏覽器中，實現(xiàn)對網(wǎng)頁的文檔對象的操作和一些用戶交互動作的處理。
而 jQuery 則是 JavaScript 的一個代碼庫（或習(xí)慣性叫類庫），它將一些在 JavaScript 開發(fā)中經(jīng)常用到的功能集合起來，以方便開發(fā)者直接使用，而不需要再用原生 JavaScript 語句寫大量代碼，同時可在不同瀏覽器間實現(xiàn)一致的效果。是當(dāng)前最流行的 JavaScript 庫之一。
1. jQuery 作為 JavaScript 的代碼庫，自然是使用 JavaScript 語言編寫的。
2. jQuery 的代碼非常規(guī)范，執(zhí)行效率也很高，是 JavaScript 編碼的優(yōu)秀范例。
3. 很多情況下，只要使用 jQuery 的方法就可以實現(xiàn)大部分的 JavaScript 功能。
PS：關(guān)于程序語言和代碼庫之間的聯(lián)系，打個比方，程序語言是原料，代碼庫則是用原料做成的半成品，而你的程序項目則是成品。你可以選擇直接用原料做，也可以選擇加入一些半成品。當(dāng)然用原料做，你可以更自由，而用半成品則效率更高。
一、JavaScript異步編程的兩個核心難點
異步I/O、事件驅(qū)動使得單線程的JavaScript得以在不阻塞UI的情況下執(zhí)行網(wǎng)絡(luò)、文件訪問功能，且使之在后端實現(xiàn)了較高的性能。然而異步風(fēng)格也引來了一些麻煩，其中比較核心的問題是：
1、函數(shù)嵌套過深
JavaScript的異步調(diào)用基于回調(diào)函數(shù)，當(dāng)多個異步事務(wù)多級依賴時，回調(diào)函數(shù)會形成多級的嵌套，代碼變成
金字塔型結(jié)構(gòu)。這不僅使得代碼變難看難懂，更使得調(diào)試、重構(gòu)的過程充滿風(fēng)險。
2、異常處理
回調(diào)嵌套不僅僅是使代碼變得雜亂，也使得錯誤處理更復(fù)雜。這里主要講講異常處理。
二、異常處理
像很多時髦的語言一樣，JavaScript 也允許拋出異常，隨后再用一個try/catch
語句塊捕獲。如果拋出的異常未被捕獲，大多數(shù)JavaScript環(huán)境都會提供一個有用的堆棧軌跡。舉個例子，下面這段代碼由于'{'為無效JSON
對象而拋出異常。
?
12345678
function JSONToObject(jsonStr) { return JSON.parse(jsonStr);}var obj = JSONToObject('{');//SyntaxError: Unexpected end of input//at Object.parse (native)//at JSONToObject (/AsyncJS/stackTrace.js:2:15)//at Object.anonymous (/AsyncJS/stackTrace.js:4:11)
堆棧軌跡不僅告訴我們哪里拋出了錯誤，而且說明了最初出錯的地方：第4 行代碼。遺憾的是，自頂向下地跟蹤異步錯誤起源并不都這么直截了當(dāng)。
異步編程中可能拋出錯誤的情況有兩種：回調(diào)函數(shù)錯誤、異步函數(shù)錯誤。
1、回調(diào)函數(shù)錯誤
如果從異步回調(diào)中拋出錯誤，會發(fā)生什么事？讓我們先來做個測試。
?
1234567
setTimeout(function A() { setTimeout(function B() { setTimeout(function C() { throw new Error('Something terrible has happened!'); }, 0); }, 0);}, 0);
上述應(yīng)用的結(jié)果是一條極其簡短的堆棧軌跡。
?
12
Error: Something terrible has happened!at Timer.C (/AsyncJS/nestedErrors.js:4:13)
等等，A 和B 發(fā)生了什么事？為什么它們沒有出現(xiàn)在堆棧軌跡中？這是因為運行C 的時候，異步函數(shù)的上下文已經(jīng)不存在了，A 和B 并不在內(nèi)存堆棧里。這3
個函數(shù)都是從事件隊列直接運行的?；谕瑯拥睦碛桑胻ry/catch
語句塊并不能捕獲從異步回調(diào)中拋出的錯誤。另外回調(diào)函數(shù)中的return也失去了意義。
?
1234567
try { setTimeout(function() { throw new Error('Catch me if you can!'); }, 0);} catch (e) {console.error(e);}
看到這里的問題了嗎？這里的try/catch 語句塊只捕獲setTimeout函數(shù)自身內(nèi)部發(fā)生的那些錯誤。因為setTimeout
異步地運行其回調(diào)，所以即使延時設(shè)置為0，回調(diào)拋出的錯誤也會直接流向應(yīng)用程序。
總的來說，取用異步回調(diào)的函數(shù)即使包裝上try/catch 語句塊，也只是無用之舉。（特例是，該異步函數(shù)確實是在同步地做某些事且容易出錯。例如，Node
的fs.watch(file,callback)就是這樣一個函數(shù)，它在目標(biāo)文件不存在時會拋出一個錯誤。）正因為此，Node.js
中的回調(diào)幾乎總是接受一個錯誤作為其首個參數(shù)，這樣就允許回調(diào)自己來決定如何處理這個錯誤。
2、異步函數(shù)錯誤
由于異步函數(shù)是立刻返回的，異步事務(wù)中發(fā)生的錯誤是無法通過try-catch來捕捉的，只能采用由調(diào)用方提供錯誤處理回調(diào)的方案來解決。
例如Node中常見的function (err, ...)
{...}回調(diào)函數(shù)，就是Node中處理錯誤的約定：即將錯誤作為回調(diào)函數(shù)的第一個實參返回。再比如HTML5中FileReader對象的onerror函數(shù)，會被用于處理異步讀取文件過程中的錯誤。
舉個例子，下面這個Node 應(yīng)用嘗試異步地讀取一個文件，還負(fù)責(zé)記錄下任何錯誤（如“文件不存在”）。
?
1234567
var fs = require('fs'); fs.readFile('fhgwgdz.txt', function(err, data) { if (err) { return console.error(err); }; console.log(data.toString('utf8'));});
客戶端JavaScript 庫的一致性要稍微差些，不過最常見的模式是，針對成敗這兩種情形各規(guī)定一個單獨的回調(diào)。jQuery 的Ajax
方法就遵循了這個模式。
?
1234
$.get('/data', { success: successHandler, failure: failureHandler});
不管API 形態(tài)像什么，始終要記住的是，只能在回調(diào)內(nèi)部處理源于回調(diào)的異步錯誤。
三、未捕獲異常的處理
如果是從回調(diào)中拋出異常的，則由那個調(diào)用了回調(diào)的人負(fù)責(zé)捕獲該異常。但如果異常從未被捕獲，又會怎么樣？這時，不同的JavaScript環(huán)境有著不同的游戲規(guī)則……
1. 在瀏覽器環(huán)境中
現(xiàn)代瀏覽器會在開發(fā)人員控制臺顯示那些未捕獲的異常，接著返回事件隊列。要想修改這種行為，可以給window.onerror
附加一個處理器。如果windows.onerror 處理器返回true，則能阻止瀏覽器的默認(rèn)錯誤處理行為。
?
123
window.onerror = function(err) { return true; //徹底忽略所有錯誤};
在成品應(yīng)用中， 會考慮某種JavaScript 錯誤處理服務(wù)， 譬如Errorception。Errorception
提供了一個現(xiàn)成的windows.onerror 處理器，它向應(yīng)用服務(wù)器報告所有未捕獲的異常，接著應(yīng)用服務(wù)器發(fā)送消息通知我們。
2. 在Node.js 環(huán)境中
在Node 環(huán)境中，window.onerror 的類似物就是process 對象的uncaughtException 事件。正常情況下，Node
應(yīng)用會因未捕獲的異常而立即退出。但只要至少還有一個uncaughtException 事件處理
器，Node 應(yīng)用就會直接返回事件隊列。
?
123
process.on('uncaughtException', function(err) { console.error(err); //避免了關(guān)停的命運！});
但是，自Node 0.8.4 起，uncaughtException 事件就被廢棄了。據(jù)其文檔所言，對異常處理而言，uncaughtException
是一種非常粗暴的機制，請勿使用uncaughtException，而應(yīng)使用Domain 對象。
Domain 對象又是什么？你可能會這樣問。Domain 對象是事件化對象，它將throw 轉(zhuǎn)化為'error'事件。下面是一個例子。
?
123456789
var myDomain = require('domain').create();myDomain.run(function() { setTimeout(function() { throw new Error('Listen to me!') }, 50);});myDomain.on('error', function(err) { console.log('Error ignored!');});
源于延時事件的throw 只是簡單地觸發(fā)了Domain 對象的錯誤處理器。
Error ignored!
很奇妙，是不是？Domain 對象讓throw
語句生動了很多。不管在瀏覽器端還是服務(wù)器端，全局的異常處理器都應(yīng)被視作最后一根救命稻草。請僅在調(diào)試時才使用它。
四、幾種解決方案
下面對幾種解決方案的討論主要集中于上面提到的兩個核心問題上，當(dāng)然也會考慮其他方面的因素來評判其優(yōu)缺點。
1、Async.js
首先是Node中非常著名的Async.js，這個庫能夠在Node中展露頭角，恐怕也得歸功于Node統(tǒng)一的錯誤處理約定。
而在前端，一開始并沒有形成這么統(tǒng)一的約定，因此使用Async.js的話可能需要對現(xiàn)有的庫進行封裝。
Async.js的其實就是給回調(diào)函數(shù)的幾種常見使用模式加了一層包裝。比如我們需要三個前后依賴的異步操作，采用純回調(diào)函數(shù)寫法如下：
?
12345678910111213141516
asyncOpA(a, b, (err, result) = { if (err) { handleErrorA(err); } asyncOpB(c, result, (err, result) = { if (err) { handleErrorB(err); } asyncOpB(d, result, (err, result) = { if (err) { handlerErrorC(err); } finalOp(result); }); });});
如果我們采用async庫來做：
?
12345678910111213141516171819202122
async.waterfall([ (cb) = { asyncOpA(a, b, (err, result) = { cb(err, c, result); }); }, (c, lastResult, cb) = { asyncOpB(c, lastResult, (err, result) = { cb(err, d, result); }) }, (d, lastResult, cb) = { asyncOpC(d, lastResult, (err, result) = { cb(err, result); }); }], (err, finalResult) = { if (err) { handlerError(err); } finalOp(finalResult);});
可以看到，回調(diào)函數(shù)由原來的橫向發(fā)展轉(zhuǎn)變?yōu)榭v向發(fā)展，同時錯誤被統(tǒng)一傳遞到最后的處理函數(shù)中。
其原理是，將函數(shù)數(shù)組中的后一個函數(shù)包裝后作為前一個函數(shù)的末參數(shù)cb傳入，同時要求：
每一個函數(shù)都應(yīng)當(dāng)執(zhí)行其cb參數(shù);cb的第一個參數(shù)用來傳遞錯誤。我們可以自己寫一個async.waterfall的實現(xiàn)：
?
12345678910111213141516171819202122
let async = { waterfall: (methods, finalCb = _emptyFunction) = { if (!_isArray(methods)) { return finalCb(new Error('First argument to waterfall must be an array of functions')); } if (!methods.length) { return finalCb(); } function wrap(n) { if (n === methods.length) { return finalCb; } return function (err, ...args) { if (err) { return finalCb(err); } methods[n](...args, wrap(n + 1)); } } wrap(0)(false); }};
Async.js還有series/parallel/whilst等多種流程控制方法，來實現(xiàn)常見的異步協(xié)作。
Async.js的問題：
在外在上依然沒有擺脫回調(diào)函數(shù)，只是將其從橫向發(fā)展變?yōu)榭v向，還是需要程序員熟練異步回調(diào)風(fēng)格。
錯誤處理上仍然沒有利用上try-catch和throw，依賴于“回調(diào)函數(shù)的第一個參數(shù)用來傳遞錯誤”這樣的一個約定。
2、Promise方案
ES6的Promise來源于Promise/A+。使用Promise來進行異步流程控制，有幾個需要注意的問題，
把前面提到的功能用Promise來實現(xiàn)，需要先包裝異步函數(shù)，使之能返回一個Promise：
?
12345678910
function toPromiseStyle(fn) { return (...args) = { return new Promise((resolve, reject) = { fn(...args, (err, result) = { if (err) reject(err); resolve(result); }) }); };}
這個函數(shù)可以把符合下述規(guī)則的異步函數(shù)轉(zhuǎn)換為返回Promise的函數(shù)：
回調(diào)函數(shù)的第一個參數(shù)用于傳遞錯誤，第二個參數(shù)用于傳遞正常的結(jié)果。接著就可以進行操作了：
?
123456789101112131415
let [opA, opB, opC] = [asyncOpA, asyncOpB, asyncOpC].map((fn) = toPromiseStyle(fn)); opA(a, b) .then((res) = { return opB(c, res); }) .then((res) = { return opC(d, res); }) .then((res) = { return finalOp(res); }) .catch((err) = { handleError(err); });
通過Promise，原來明顯的異步回調(diào)函數(shù)風(fēng)格顯得更像同步編程風(fēng)格，我們只需要使用then方法將結(jié)果傳遞下去即可，同時return也有了相應(yīng)的意義：
在每一個then的onFullfilled函數(shù)（以及onRejected）里的return，都會為下一個then的onFullfilled函數(shù)（以及onRejected）的參數(shù)設(shè)定好值。
如此一來，return、try-catch/throw都可以使用了，但catch是以方法的形式出現(xiàn)，還是不盡如人意。
3、Generator方案
ES6引入的Generator可以理解為可在運行中轉(zhuǎn)移控制權(quán)給其他代碼，并在需要的時候返回繼續(xù)執(zhí)行的函數(shù)。利用Generator可以實現(xiàn)協(xié)程的功能。
將Generator與Promise結(jié)合，可以進一步將異步代碼轉(zhuǎn)化為同步風(fēng)格：
?
1234567891011
function* getResult() { let res, a, b, c, d; try { res = yield opA(a, b); res = yield opB(c, res); res = yield opC(d); return res; } catch (err) { return handleError(err); }}
然而我們還需要一個可以自動運行Generator的函數(shù)：
?
123456789101112131415161718192021222324252627282930
function spawn(genF, ...args) { return new Promise((resolve, reject) = { let gen = genF(...args); function next(fn) { try { let r = fn(); if (r.done) { resolve(r.value); } Promise.resolve(r.value) .then((v) = { next(() = { return gen.next(v); }); }).catch((err) = { next(() = { return gen.throw(err); }) }); } catch (err) { reject(err); } } next(() = { return gen.next(undefined); }); });}
用這個函數(shù)來調(diào)用Generator即可：
?
1234567
spawn(getResult) .then((res) = { finalOp(res); }) .catch((err) = { handleFinalOpError(err); });
可見try-catch和return實際上已經(jīng)以其原本面貌回到了代碼中，在代碼形式上也已經(jīng)看不到異步風(fēng)格的痕跡。
類似的功能有co/task.js等庫實現(xiàn)。
4、ES7的async/await
ES7中將會引入async function和await關(guān)鍵字，利用這個功能，我們可以輕松寫出同步風(fēng)格的代碼，
同時依然可以利用原有的異步I/O機制。
采用async function，我們可以將之前的代碼寫成這樣：
?
12345678910111213
async function getResult() { let res, a, b, c, d; try { res = await opA(a, b); res = await opB(c, res); res = await opC(d); return res; } catch (err) { return handleError(err); }} getResult();
和Generator Promise方案看起來沒有太大區(qū)別，只是關(guān)鍵字換了換。
實際上async
function就是對Generator方案的一個官方認(rèn)可，將之作為語言內(nèi)置功能。
async function的缺點：
await只能在async function內(nèi)部使用，因此一旦你寫了幾個async function，或者使用了依賴于async
function的庫，那你很可能會需要更多的async function。
目前處于提案階段的async
function還沒有得到任何瀏覽器或Node.JS/io.js的支持。Babel轉(zhuǎn)碼器也需要打開實驗選項，并且對于不支持Generator的瀏覽器來說，還需要引進一層厚厚的regenerator
runtime，想在前端生產(chǎn)環(huán)境得到應(yīng)用還需要時間。
以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助。
基本上所有語言(有eval的)都不建議用 eval, 除非您很確定知道自己在干甚麼又別無他法.
eval 之所以不建議使用是因為安全性隱患, 此話適用於所有編程語言, 正常來說只有兩種處境下才會用 eval, 一是在寫病毒碼, 如以 utf-7 (沒寫錯, 是utf-7) 編寫代碼 讓使用者, 甚至防毒軟件都看不懂真正要執(zhí)行的代碼是甚麼, 另一個是做測試, 除錯; 成品 (production) 絕不該出現(xiàn) eval 的語句.
這是因為 eval 的東西都不會再有別的防御機制去審視要執(zhí)行的是甚麼, 比如您要 eval 一個表單里的某串 text, 這就足以讓植入式(病毒)碼 (injection code) 長驅(qū)直入, 成為您頁面里的一部分.
當(dāng)然, 一個更低層次的問題就是, 其實與其在 eval 里寫代碼, 還不如寫句正正式式的代碼, 在 eval 里要寫很多 \" \' \\ , 寫著寫著都眼花了.
重慶分公司
重慶分公司
